Subject: Use of SNMP for updating COS tables

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Thu, 6 Jul 95 15:42:42 EDT

Before Marcia's append on this subject takes on the character of an
"official" IBM position, I want to raise a serious concern that some of
us here have with the use of SNMP for this function.  The concern is not
unique to COS tables:  it applies to any attempt to extend SNMP beyond
monitoring and control, to cover network configuration as well.

The difficulty centers on how to handle validation of the configuration
updates that an SNMP Management Station might send to an agent.  In
general, whether a proposed set of configuration parameters is valid is
not only a matter of their internal consistency:  the proposed set must
also be consistent with other configuration parameters, and in some cases
with operational parameters as well, at the target system.  So who will
be in a position to perform this validation?

   -  The Management Station?  Not really, because even if it used SNMP
      to retrieve from the agent the values of the other parameters to
      use in the validation, these values might have changed by the time
      the "validated" configuration update arrives.  A second problem
      here is that once the COS tables have been made read-create,
      there's no way for an agent to tell whether an update comes from a
      sophisticated COS-update application, which takes the time to
      validate the updates it send, or from a simple MIB browser, where
      the values are whatever the operator has decided to enter.

   -  The agent?  There are at least two problems here.  One is the cost
      of putting the validation logic on every APPN node.  The second is
      whether it is feasible for the agent to retrieve the information
      necessary to do the validation before the SNMP request has timed
      out.  Even if all of this information is "local" to the agent,
      experience has shown that time outs become an issue when the SNMP
      subagent has to interact with multiple node components and/or with
      other subagents in the course of processing an SNMP request.

I'm not at this point saying that the use of SNMP for updating COS tables
is completely out of the question.  Maybe such updates are especially
easy to validate, so that the general concerns about SNMP updates for
configuration information don't apply to them.  I *am* saying, however,
that we need to look closely at the details of how such a function could
be implemented, at both the agents and the Management Station, before we
glibly say that "network management can handle it."

A couple of other points:

Dave Finnie has asked the question of whether SNMP supports any kind of
multicast function, to automatically distribute a configuration update to
multiple nodes.  The answer is, no:  the Management Station must have
separate, one-on-one interactions with each node it wants to update.

Dave has also asked about the implications of basing COS updates on
SNMP when some APPN products do not support SNMP.  Now I certainly can't
object to a design that gets more network management capabilities into
more APPN products, but there's no magic here:  for the foreseeable
future, there will continue to be some APPN products that don't support
SNMP.  This situation is tolerable when SNMP is limited to monitoring and
control, since individual products can add this support individually,
when and if they determine that "being manageable" is to their benefit,
without really impacting the operation of the network.  If, however, COS
updates are based on SNMP, then a product's role in the network will be
compromised if it doesn't support SNMP, and this strikes me as a
different matter altogether.

Bob Moore

---

From: David Matusow <[email-masked]>
Date: Thu, 6 Jul 1995 14:49:40 -42000

The use of SNMP for configuration of APPN is quite an interesting 
juxtiposition, as APPN management is *not* through SNMP.  There are many 
APPN nodes that also support this method, but this is NOT the native 
interface.  Management services should be used, as this is the 
architected method of interface.  Its quite convenient when one can use 
an open interface, but this should not be expected and to design for its 
use is quite interesting.

I think Bob hit the nail on the head. Its nice to look at APPN as an open 
architecture, but this does not mean that open interfaces are to be 
used.  Until APPN architecture is changed (along with all of the nodes 
that are out there already), this is not a very viable answer.

David Matusow